-
-
Notifications
You must be signed in to change notification settings - Fork 76
feat: add VZVmnetNetworkDeviceAttachment support (macOS 26.0)
#205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: add VZVmnetNetworkDeviceAttachment support (macOS 26.0)
#205
Conversation
VmnetNetworkDeviceAttachment support (macOS 26.0)VZVmnetNetworkDeviceAttachment support (macOS 26.0)
6617c8f to
6a1f741
Compare
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]>
|
This can be used by multiple processes like this:
|
5a7a116 to
72cc1d4
Compare
In this procedure, I confirmed that VMs launched from multiple processes can share networks with each other. 👍🏻 |
72cc1d4 to
9506cbd
Compare
Added unit test and |
I'll try this added xpc package with lima to make it work. Until then, it's a draft. |
7bf24c1 to
007c2a5
Compare
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]>
aba95bd to
ba619f5
Compare
d3fad75 to
7a58378
Compare
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]>
7a58378 to
33858c0
Compare
nirs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not review most of this change, just the stange part of about marking bridged mode as depracated.
f048f6e to
3b512d7
Compare
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]>
Signed-off-by: Norio Nomura <[email protected]>
|
I'll add:
|
Signed-off-by: Norio Nomura <[email protected]>
| // This is only supported on macOS 26 and newer, error will be returned on older versions. | ||
| // - https://developer.apple.com/documentation/vmnet/vmnet_network_create_with_serialization(_:_:)?language=objc | ||
| func NewNetworkWithSerialization(serialization unsafe.Pointer) (*Network, error) { | ||
| func NewNetworkWithSerialization(serialization xpc.Object) (*Network, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this change, if I have xpc_object_t I got from a xpc service, I need to wrap it like this, right?
// serialization is xpc_object_t
network, err := NewNetworkWithSerialization(xpc.NewObject(serialization))So we did not really got rid of the unsafe.Pointer - I think we cannot avoid this since this is the only way to integrate with code retuning xpc_object_t. The vmnet interface vment_network_create_with_serialization() accepts xpc_object_t so we cannot implement it without accepting xpc_object.
But I think this wrapping makes sense to minimize the scope of a raw xpc_object_t.
Update to consume API changes in the vz PR[1] commit[2]. - vment.NewNetworkWithSerialization() accepts now xpc.Object interface instead of xpc_object_t. We can wrap the raw xpc_object_t with xpc.NewObject(). - Updated dependencies [1] Code-Hex/vz#205 [2] norio-nomura/vz@9c98b6b
Update to consume API changes in the vz PR[1] commit[2]. - vment.NewNetworkWithSerialization() accepts now xpc.Object interface instead of xpc_object_t. We can wrap the raw xpc_object_t with xpc.NewObject(). - Updated dependencies [1] Code-Hex/vz#205 [2] norio-nomura/vz@9c98b6b
|
I tested the latest version, it works for me. |
Signed-off-by: Norio Nomura <[email protected]>
Call `ReleaseOnCleanup()` explicitly if needed. Signed-off-by: Norio Nomura <[email protected]>
16c89d9 to
c68bc89
Compare
Update to consume API changes in the vz PR[1] commit[2]. - vment.Network.Raw() removed [1] Code-Hex/vz#205 [2] norio-nomura/vz@c68bc89
Signed-off-by: Norio Nomura <[email protected]>
Signed-off-by: Norio Nomura <[email protected]>
c68bc89 to
f92e6f3
Compare
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]>
|
I think the approximately necessary APIs have been added. |
|
@norio-nomura Does the xpc package need to be public? If it fits within internal, I don't think we need to add tests. |
It depends on the |
We need the xpc.NewObject() for creating a vment_network_ref with serialization. Here is an example usage in vmnet-broker test vm: If vmnet.NewNetworkWithSerialization() will accept xpc_object_t (unsafe.Pointer), the xpc package is not needed in this project and can be part of Lima or available as separate package. |
|
Unit tests added to |
Based on `VMNET_SHARED_MODE`, and `VMNET_HOST_MODE` ```yaml networks: - vzShared: true - vzHost: true ``` But, to sharing network between multiple VMs, `VZVmnetNetworkDeviceAttachment` requires VMs are launched by same process. It depends on Code-Hex/vz#205 Signed-off-by: Norio Nomura <[email protected]> # Conflicts: # go.sum
Signed-off-by: Norio Nomura <[email protected]> `vmnet`: Fix golangci-lint-v2 violations Signed-off-by: Norio Nomura <[email protected]> `vmnet`: if iface.EnableVirtioHeader { packetSize += virtioNetHdrSize } Signed-off-by: Norio Nomura <[email protected]>
Signed-off-by: Norio Nomura <[email protected]>
Use `*FileAdaptorForInterface` APIs in `TestVmnetSharedModeAllowsCommunicationBetweenMultipleVMs`: - `vmnet.DatagramFileAdaptorForInterface` - `vmnet.DatagramNextFileAdaptorForInterface` Since they are compatible with `vz.NewFileHandleNetworkDeviceAttachment`. Signed-off-by: Norio Nomura <[email protected]>
- Fix `NewArray` with empty slices. - Change `New*` to return actual typed instance instead of `Object` Signed-off-by: Norio Nomura <[email protected]>
701968f to
7420c05
Compare
feat: add
VZVmnetNetworkDeviceAttachmentsupport (macOS 26.0)VZVmnetNetworkDeviceAttachmentis an API that creates vmnet devices on VMs added in macOS 26.see: https://developer.apple.com/documentation/virtualization/vzvmnetnetworkdeviceattachment?language=objc
It does not require the
com.apple.vm.networkingentitlement nor root privileges.HostModeandSharedModeare supported.In order for multiple VMs to communicate with each other in
SharedMode, they must be started in the same executable and the sameVmnetNetworkmust be passed toNewVmnetNetworkDeviceAttachment()to create an attachment.This change adds:
vz.VmnetNetworkDeviceAttachmentrepresentsVZVmnetNetworkDeviceAttachmentin Govmnetpackage to use vmnet APIs that added on macOS 26.0Returnrepresentsvmnet_return_taserrorErrSuccess,ErrFailure, ...Moderepresentsoperating_modes_tHostMode,SharedModeNetworkConfigurationrepresentsvmnet_network_configuration_tNetworkrepresentsvmnet_network_refInterfacerepresentsinterface_ref*FileAdaptorForInterfaces support File Handle based network device APIs on QEMU, krunkit, andvz.NewFileHandleNetworkDeviceAttachmentvz_test.TestVmnetSharedModeAllowsCommunicationBetweenMultipleVMsvz_test.TestVmnetSharedModeWithConfiguringIPv4pkg/xpcpackage that providing<xpc/xpc.h>APIs to support implementing Mach service server and clientvz_test.TestVmnetNetworkShareModeSharingOverXpcTestVmnetNetworkShareModeSharingOverXpctests sharingvmnet.NetworkinSharedModeover XPC communication.This test registers test executable as an Mach service and launches it using
launchctl.The launched Mach service provides
vmnet.Networkserialization to clients upon request, after bootinga VM using the provided
vmnet.Networkto ensure the network is functional on the server side.The client boots VM using the provided
vmnet.Networkserialization.Edit: on macOS 26.2, "the same executable" restriction seems to be relaxed.
VZVmnetNetworkDeviceAttachmentseems to allow connecting to subnet created by a different executable.vmnet_interface_start_with_networkseems to allow connecting to subnet created by an executable at same path? (may changing CDHash not affect?)Which issue(s) this PR fixes:
Mentioned in #198 (comment)